Use the tag created by the build action when running npm version,
otherwise the checkout actions gets the HEAD of the commit that
triggered the original workflow resulting in the usage of the previous
version.
Potentially in the future, instead of triggering the build manually we
could consider using the tag as a trigger for the build process and then
all the dependent workflows should work fine. It's good we have this
manual for validation, and we workaround some of the limitations before
we invest more into more automation
## About the changes
Automate some of our release steps in the same workflow. This gives us
the ability to opt-out some of the jobs which allows us to release
patches to older versions without setting that patch as the latest
version (currently not covering docker publish but if this test works
successfully we might include it as well).
This comes from tests in our enterprise repository.
We'd like to get this out so you can get away with only defining a CA
certificate, the current iteration requires CA, CERT and KEY in order to
work. This PR splits it up and allows you to configure one.
---------
Co-authored-by: Egor Stronhin <6418221+egor-xyz@users.noreply.github.com>
Final rank has always been ordering correctly by default. But after 5.12
I see some issues that sometimes it is not ordered. Just to be extra
sure, I am for ordering it.
Hello!
We wanted to make the docs less impersonal, so we decided to add
contributors. Now each doc page that has an `editUrl` (i.e, isn't
generated) shows a list of everyone that contributed to it.
This list is generated by:
1. Running `swizzle` on the `DocItem/Footer` in Docusaurus.
2. Grabbing metadata for the current file using an internal docusaurus
API (Thank you to @homotechsual for the help there)
3. Getting the commits to the file in question with the GitHub API
<details>
<summary> Here's the command I ran, for posterity </summary>
<code>npm run swizzle @docusaurus/theme-classic DocItem/Footer --
--wrap</code>
</details>
## Discussion points
1. Design. What do you think of the layout?
2. Right now I'm hardcoding the info of Unleash team members. This
creates a small maintenance burden, but it's something we wanted to add.
This PR allows very simple project creation. You can add a name and
description. The ID is generated for you at the moment (we'll fix this
later). Nothing else works, but the project is created successfully.
This PR adds a very rough first implementation of the look of the new
project form. *It is not final and does not work yet*.
The important part here is that the layout is roughly right (we'll
adjust spacing etc later) and that we've got all the basic elements
present.
I'll hook it up to actually work in an upcoming PR.
The missing icon, text alignment, etc, will also be solved later.
Add a flag to enable/disable the new UI for project creation.
This flag is separate from the impl on the back end so that we can
enable one without the other (but uses flag dependencies in Unleash, so
that we can never enable the new UI without the new back end).
I have not set the flag to `true` in server startup because the form
doesn't work yet, so it's a manual step for now.
This PR removes the workaround introduced in
https://github.com/Unleash/unleash/pull/6931. After
https://github.com/ivarconr/unleash-enterprise/pull/1268 has been
merged, this should be safe to apply.
Notably, this PR:
- tightens up the type for the enable change request function, so we can
use that to inform the code
- skips trying to do anything with an empty array
The last point is less important than it might seem because both the env
validation and the current implementation of the callback is essentially
a no-op when there are no envs. However, that's hard to enforce. If we
just exit out early, then at least we know nothing happens.
Optionally, we could do something like this instead, but I'm not sure
it's better or worse. Happy to take input.
```ts
const crEnvs = newProject.changeRequestEnvironments ?? []
await this.validateEnvironmentsExist(crEnvs.map((env) => env.name));
const changeRequestEnvironments =
await enableChangeRequestsForSpecifiedEnvironments(crEnvs,);
data.changeRequestEnvironments = changeRequestEnvironments;
```
Hello,
As discussed with @sighphyre, there were a number of problems with the
examples docs. This addresses the most pressing ones, namely:
- Corrected the link to the Jira plugin
- Added deprecation warning to Jira Server pages
- Removed the incomplete markdown table at the end of articles, and the
references to it
---------
Co-authored-by: Simon Hornby <liquidwicked64@gmail.com>
