Mirrors/unleash.unleash
1
0
Fork 0
mirror of https://github.com/Unleash/unleash.git synced 2024-10-28 19:06:12 +01:00
Code Issues Projects Releases Wiki Activity
a8206f5118
unleash.unleash/.gitignore

95 lines
1.4 KiB
Plaintext
Raw Normal View History

Update .gitignore
2015-01-27 11:10:29 +01:00
node_modules
use lerna for multipackaging
2016-06-18 09:19:57 +02:00
lerna-debug
npm-debug
Update .gitignore
2015-01-27 11:10:29 +01:00
.DS_Store
Feature/setup typescript This sets up the typescript compiler. Allowing gradual migration to typescript. Co-authored-by: Christopher Kolstad <chriswk@getunleash.ai> Co-authored-by: Ivar Conradi Østhus <ivarconr@gmail.com> Co-authored-by: Fredrik Oseberg <fredrik.oseberg@getunleash.ai> Co-authored-by: Clint Checkett <clintchecketts@churchofjesuschrist.org> fixes: #676
2021-02-12 11:42:00 +01:00
/dist
Fix/project role permission grant (#8084) ## Background In #6380 we fixed a privilege escalation bug that allowed members of a project that had permission to add users to the project with roles that had a higher permission set than themselves. The PR linked essentially constricts you only be able to assign users to roles that you possess yourself if you are not an Admin or Project owner. This fix broke expectations for another customer who needed to have a project owner without the DELETE_PROJECT permission. The fix above made it so that their custom project owner role only was able to assign users to the project with the role that they posessed. ## Fix Instead of looking directly at which role the role granter has, this PR addresses the issue by making the assessment based on the permission sets of the user and the roles to be granted. If the granter has all the permissions of the role being granted, the granter is permitted to assign the role. ## Other considerations The endpoint to get roles was changed in this PR. It previously only retrieved the roles that the user had in the project. This no-longer makes sense because the user should be able to see other project roles than the one they themselves hold when assigning users to the project. The drawback of returning all project roles is that there may be a project role in the list that the user does not have access to assign, because they do not hold all the permissions required of the role. This was discussed internally and we decided that it's an acceptable trade-off for now because the complexities of returning a role list based on comparing permissions set is not trivial. We would have to retrieve each project role with permissions from the database, and run the same in-memory check against the users permission to determine which roles to return from this endpoint. Instead we opted for returning all project roles and display an error if you try to assign a role that you do not have access to. ## Follow up When this is merged, there's no longer need for the frontend logic that filters out roles in the role assignment form. I deliberately left this out of the scope for this PR because I couldn't wrap my head around everything that was going on there and I thought it was better to pair on this with @chriswk or @nunogois in order to make sure we get this right as the logic for this filtering seemed quite complex and was touching multiple different components. --------- Co-authored-by: Fredrik Strand Oseberg <fredrikstrandoseberg@Fredrik-sin-MacBook-Pro.local>
2024-09-10 20:35:45 +02:00
.vscode
Update .gitignore
2015-01-27 11:10:29 +01:00
Initial commit
2014-09-29 14:50:46 +02:00
# Logs
logs
*.log
# Runtime data
pids
*.pid
*.seed
# Directory for instrumented libs generated by jscoverage/JSCover
lib-cov
# Coverage directory used by tools like istanbul
fix: include jest coverage files (POC)
2022-05-20 11:14:41 +02:00
# coverage
fix: do not produce report.json in coverage action for now
2022-05-20 19:29:14 +02:00
coverage/lcov-report
Initial commit
2014-09-29 14:50:46 +02:00
# Compiled binary addons (http://nodejs.org/api/addons.html)
build/Release
Move unleash-server to top level.
2014-10-31 16:35:35 +01:00
# liquibase stuff
/sql
unleash-db.jar
added server side validation of feature name
2014-11-01 11:47:21 +01:00
unleash-server.tar.gz
# idea stuff:
ignore all idea files with .gitignore
2016-05-03 12:12:37 +02:00
.idea/*
added docker container and vagrant
2015-06-19 14:11:02 +02:00
.vagrant/
gitignore: added Visual Stuido Code IDE ignores
2016-04-30 10:47:17 +02:00
# Visual Studio Code
jsconfig.json
ignored vscode files
2016-04-30 22:11:16 +02:00
typings
use ava as testrunner
2016-11-13 15:41:35 +01:00
.nyc_output
We should not use package-lock.json
2017-11-04 12:09:12 +01:00
# We use yarn.lock
package-lock.json
chore(documentation): Added Docusaurus with a website fixes #355
2018-11-20 20:34:42 +01:00
# Website stuff
/website/build
/website/backers.json
/website/node_modules
/website/translated_docs
Make Appinstance registration include environment (#1014)
2021-10-12 10:39:28 +02:00
/website/i18n/*
.env
Test npm publish (#3554) ## About the changes https://github.blog/changelog/2022-10-24-npm-v9-0-0-released/ introduced a breaking change in the way they handle files inside package.json which caused some issues with the way we pack and distribute Unleash: > npm pack now follows a strict order of operations when applying ignore rules. If a files array is present in the package.json, then rules in .gitignore and .npmignore files from the root will be ignored. What we discovered is that when having a nested .gitignore (the one we have inside frontend), `npm publish` was taking that nested .gitignore into account (despite the fact that we also have a package.json with files inside the same folder). We tricked this by removing the `build` folder from `frontend/.gitignore` and instead adding it into the root `.gitignore` which is being ignored by `npm publish` following what's stated in the release note above. ----------------- Co-authored-by: Gard Rimestad <gard@getunleash.io>
2023-04-18 15:44:19 +02:00
# Ignore frontend build
frontend/build
docs: auto-generate remaining server-side SDK docs (#2858) This PR builds on the preceding doc auto-generation PRs and generates documentation for the remaining server-side SDKs. ## Why Refer to https://github.com/Unleash/unleash/pull/2809 for more context about generating SDK docs. ## What - Adds generation for the remaining server-side SDKs - Moves generated docs from the `/reference/sdks` directory to `/generated` directory. - Makes sure that the URLs do not change because of the move by using the `slug` frontmatter property. - replaces relative github links in the markdown documents so that they become absolute github links. (refer to the next section) - Updates some image styling so that it doesn't apply to readme badges (we don't need them using `display: block`) ### On link replacing: This PR adds handling of links in the generated documentation. Specifically, it changes links in one case: Relative links to github. Links to code and other files in the repository. These are prefixed with the repository's URL. While this should work in most cases, it will fail in cases where the links to the files are not on the repository's primary branch. (typically main, but could also be "v3", for instance). In these cases, the links will get a double branch in the URL and will fail. However, I see no easy way around this (though suggestions are definitely accepted!), and think it's a fair tradeoff. It takes the links from "definitely failing" to "will work in the vast majority of cases". Note: I originally also wanted to handle the case where the link is an absolute link to docs.getunleash.io. We could turn these into relative urls to avoid full page reloads and enjoy a smoother experience. However, the client-side redirects don't work correctly if the relative URL goes to a redirect page, so you end up with a 404 page. As such, I think it's better to leave the links as absolute for now.
2023-01-13 12:40:28 +01:00
feat: generate orval types with dependent features (#4902)
2023-10-02 12:35:20 +02:00
# Ignore orval apis
frontend/src/openapi/apis
chore: generate types (#5074) Generate orval types --------- Signed-off-by: andreas-unleash <andreas@getunleash.ai>
2023-10-18 08:55:07 +02:00
frontend/src/openapi/index.ts
feat: generate orval types with dependent features (#4902)
2023-10-02 12:35:20 +02:00
docs: auto-generate remaining server-side SDK docs (#2858) This PR builds on the preceding doc auto-generation PRs and generates documentation for the remaining server-side SDKs. ## Why Refer to https://github.com/Unleash/unleash/pull/2809 for more context about generating SDK docs. ## What - Adds generation for the remaining server-side SDKs - Moves generated docs from the `/reference/sdks` directory to `/generated` directory. - Makes sure that the URLs do not change because of the move by using the `slug` frontmatter property. - replaces relative github links in the markdown documents so that they become absolute github links. (refer to the next section) - Updates some image styling so that it doesn't apply to readme badges (we don't need them using `display: block`) ### On link replacing: This PR adds handling of links in the generated documentation. Specifically, it changes links in one case: Relative links to github. Links to code and other files in the repository. These are prefixed with the repository's URL. While this should work in most cases, it will fail in cases where the links to the files are not on the repository's primary branch. (typically main, but could also be "v3", for instance). In these cases, the links will get a double branch in the URL and will fail. However, I see no easy way around this (though suggestions are definitely accepted!), and think it's a fair tradeoff. It takes the links from "definitely failing" to "will work in the vast majority of cases". Note: I originally also wanted to handle the case where the link is an absolute link to docs.getunleash.io. We could turn these into relative urls to avoid full page reloads and enjoy a smoother experience. However, the client-side redirects don't work correctly if the relative URL goes to a redirect page, so you end up with a 404 page. As such, I think it's better to leave the links as absolute for now.
2023-01-13 12:40:28 +01:00
# Generated docs
website/docs/reference/api/**/sidebar.js
chore: add auto-generated doc index to gitignore (#4198) I've seen this one pop up a couple times. It's part of our openapi docusaurus integration and should be ignored.
2023-07-10 16:28:34 +02:00
website/docs/reference/api/**/**.info.mdx
docs: auto-generate remaining server-side SDK docs (#2858) This PR builds on the preceding doc auto-generation PRs and generates documentation for the remaining server-side SDKs. ## Why Refer to https://github.com/Unleash/unleash/pull/2809 for more context about generating SDK docs. ## What - Adds generation for the remaining server-side SDKs - Moves generated docs from the `/reference/sdks` directory to `/generated` directory. - Makes sure that the URLs do not change because of the move by using the `slug` frontmatter property. - replaces relative github links in the markdown documents so that they become absolute github links. (refer to the next section) - Updates some image styling so that it doesn't apply to readme badges (we don't need them using `display: block`) ### On link replacing: This PR adds handling of links in the generated documentation. Specifically, it changes links in one case: Relative links to github. Links to code and other files in the repository. These are prefixed with the repository's URL. While this should work in most cases, it will fail in cases where the links to the files are not on the repository's primary branch. (typically main, but could also be "v3", for instance). In these cases, the links will get a double branch in the URL and will fail. However, I see no easy way around this (though suggestions are definitely accepted!), and think it's a fair tradeoff. It takes the links from "definitely failing" to "will work in the vast majority of cases". Note: I originally also wanted to handle the case where the link is an absolute link to docs.getunleash.io. We could turn these into relative urls to avoid full page reloads and enjoy a smoother experience. However, the client-side redirects don't work correctly if the relative URL goes to a redirect page, so you end up with a 404 page. As such, I think it's better to leave the links as absolute for now.
2023-01-13 12:40:28 +01:00
website/docs/generated
task: Add Unit test result check task (#3695) After a Team Retro, one of our squads felt like we needed more data on our test suites. This is the first effort to make our test results easier to grab. It uses the test-reporter action to add a github check to our main build and PR builds with our test results. This at least should make it easier to parse which tests are failing. However, it does not give us trends. So it does not yet make it easier to decide which tests are flaky just from a quick view. --------- Co-authored-by: Gastón Fournier <gaston@getunleash.io>
2023-05-25 13:03:54 +02:00
reports/jest-junit.xml
ignore .yarn changes and delete existing tracked files (#7333) This PR follows Yarn's official suggestion on [which files should be gitignored](https://yarnpkg.com/getting-started/qa#which-files-should-be-gitignored) and also deletes the `install-state.gz` files that are already committed. I've used the gitignore option that isn't for "zero-installs" because I'm not sure whether we're using them or not. I'm guessing we're not, but we can always update that later if we are. The doc says that the install-state file "is an optimization file that you shouldn't ever have to commit. It simply stores the exact state of your project so that the next commands can boot without having to resolve your workspaces all over again."
2024-06-10 13:41:11 +02:00
# Yarn (https://yarnpkg.com/getting-started/qa#which-files-should-be-gitignored)
.pnp.*
.yarn/*
!.yarn/patches
!.yarn/plugins
!.yarn/releases
!.yarn/sdks
!.yarn/versions
task: Yarn v4 (#7457) Moves to Yarn v4 --------- Co-authored-by: Alvin Bryan <107407814+alvinometric@users.noreply.github.com>
2024-06-27 12:52:43 +02:00
frontend/.yarn/*
!frontend/.yarn/patches
!frontend/.yarn/plugins
!frontend/.yarn/releases
!frontend/.yarn/sdks
!frontend/.yarn/versions
docker/.yarn/*
!docker/.yarn/patches
!docker/.yarn/plugins
!docker/.yarn/releases
!docker/.yarn/sdks
!docker/.yarn/versions
website/.yarn/*
!website/.yarn/patches
!website/.yarn/plugins
!website/.yarn/releases
!website/.yarn/sdks
!website/.yarn/versions
Reference in New Issue Copy Permalink