ci(forks): ensure that fork pipelines are executed correctly
What does this MR do?
ci(forks): ensure that fork pipelines are executed correctly
We were comparing against CI_MERGE_REQUEST_SOURCE_PROJECT_PATH which always points to the fork instead of the project the pipeline is run in.
So for example we have an MR created from fork/gitlab-ui and the person
who forked gitlab-ui created the MR, the pipeline was executed in the
context of: fork/gitlab-ui
. If then a GitLab team member ran the Run pipeline
in the context of the MR, the pipeline was executed in context
of gitlab-org/gitlab-ui
, but some of the jobs, e.g. review
,
create_integration_branch
were not executed.
By utilizing CI_PROJECT_PATH we fix this, because:
- Pipelines run in
fork/gitlab-ui
will point to that - Pipelines run in
gitlab-org/gitlab-ui
will point to that
ci: Use semantic release with rules
support
Make use of the new rules
syntax with a newer version of the semantic
release template.
Does this MR meet the acceptance criteria?
Conformity
-
Code review guidelines. -
GitLab UI's contributing guidlines. -
If it changes a Pajamas-compliant component's look & feel, the MR has been reviewed by a UX designer. -
If it changes GitLab UI's documentation guidelines, the MR has been reviewed by a Technical Writer. -
If the MR changes a component's API, integration MR(s) have been opened in the following projects to ensure that the @gitlab/ui
package can be upgraded quickly after the changes are released:-
GitLab: mr_url -
CustomersDot: mr_url -
Status Page: mr_url
-
-
Added the ~"component:*"
label(s) if applicable.
Security
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
-
Label as security and @ mention @gitlab-com/gl-security/appsec
-
Security reports checked/validated by a reviewer from the AppSec team
Accessibility
If this MR adds or modifies a component, take a few moments to review the following:
-
All actions and functionality can be done with a keyboard. -
Links, buttons, and controls have a visible focus state. -
All content is presented in text or with a text equivalent. For example, alt text for SVG, or aria-label
for icons that have meaning or perform actions. -
Changes in a component’s state are announced by a screen reader. For example, changing aria-expanded="false"
toaria-expanded="true"
when an accordion is expanded. -
Color combinations have sufficient contrast.