Description
🚀 Feature request
Please do not deprecate and remove the baseUrl
flag in the protractor schema.
Command (mark with an x
)
- [ ] new
- [ ] build
- [ ] serve
- [ ] test
- [ x ] e2e
- [ ] generate
- [ ] add
- [ ] update
- [ ] lint
- [ ] xi18n
- [ ] run
- [ ] config
- [ ] help
- [ ] version
- [ ] doc
Description
In our CI/CD system, we run our e2e tests as a part of our pre-merge validations, which include deploying the SPA configured to run against our staging API. In order to do this cleanly, and without namespace conflicts/races, we give each of these applications their own base-href, as follows:
ng build
--configuration=staging
--output-path=./dist-e2e
--base-href=/ci-cd-draft-build-${JOB_NUMBER}/
This is then uploaded to S3, and tested as follows:
ng e2e --baseUrl=https://<s3-bucket>/ci-cd-draft-build-${JOB_NUMBER}/
We also use these draft builds to perform Beta feature usability tests, product demos, and a variety of other activities that are greatly enhanced by having a fully functioning UI. Similarly, we publish whitelabel UI's for our customers, which we also run protractor-driven acceptance tests against, and whose base-url's vary greatly.
Just now, I noticed this message:
Option "baseUrl" is deprecated: Use "baseUrl" in the Protractor config file instead.
Which I traced to the following entry in the protractor schematic.
"baseUrl": {
"type": "string",
"description": "Base URL for protractor to connect to.",
"x-deprecated": "Use \"baseUrl\" in the Protractor config file instead."
}
As our buildUrl
value is not known ahead of time, we cannot easily use the protractor config file; while we could attempt to inject it via some form of environment parameter, modifying environment parameters is more cumbersome than adding a commandline flag.
Describe the solution you'd like
We do not want this flag to be removed. It's not harming anyone, why is it being removed?
Describe alternatives you've considered
Writing a configuration file for CI/CD, for every customer, environment, and build target we have. This will litter our project with config files, and we'd really like to avoid that.
Activity
krotscheck commentedon Mar 19, 2019
Seems like the new flavor of protractor builders supports the buildUrl flag. So I guess the current deprecation flag is... false?
alan-agius4 commentedon Mar 20, 2019
Hi @krotscheck, the deprecation of baseUrl is intentional. The main reason why this is being deprecated is due to additional code to maintain and the increase of the scope of the CLI.
The new builders have the baseUrl in place, because of our deprecation policy. Whatever is deprecated needs to stay around for 2 major versions, so consumers have enough time to adjust to the changes required.
I'll leave this issue open for the time being to see what is the feedback on the community and other team members about this.
jkyoutsey commentedon Jun 14, 2019
We have the exact same issue and desire. We want our CI/CD to define the base-url rather than using different config files that only differ in this one setting.
deankostomaj commentedon Jun 24, 2019
Same issue here. It seems unreasonable to have multiple configurations just because of one variable. Also, there is a problem with dynamic baseUrls which get generated during CI.
DarthOpto commentedon Jul 12, 2019
so we did this to get around this insanity:
Protractor.config
const baseUrl = process.env.baseUrl ? process.env.baseUrl : 'default url';
package.json under scripts
e2e-qa: "baseUrl=http://qa.url ng e2e --suite"
add a script for each URL you want to run with.
Run them this way:
npm run e2e-qa -- testsuite
Hope this helps.
kumaravnish commentedon Aug 24, 2019
Any resolution on this? We need the baseUrl feature as well, as our URLs are dynamic in the CI process.
mkalam-alami commentedon Aug 27, 2019
The depreciation caused CI/CD problems for us as well during migration to Angular 8 (not only
--baseUrl
was deprecated but it actually did not work anymore, using cli 8.2.2 + protractor 5.4.0).We switched to @DarthOpto's approach of custom environment variables set in the
protractor.conf.js
. While it would have been more comfortable to keep the flags, to be honest it is an acceptable alternative and barely more effort to set up.Maybe the warning could just be updated to make that suggestion, something like:
vikerman commentedon Aug 29, 2019
We decided not to deprecate this flag.
baseUrl
i… #154794 remaining items